Proposed by Ian Corne (profile, biography) Don't forget to submit this proposal to official Google Melange site too!
1. What is this project about
1. Current situation
Many different frameworks use their own implementation to do http messaging.
Each has their own strength and downsides. This situation makes using a different framework cumbersome when working on new projects in a new framework. Frameworks such as Seaside also use their own implementation and result in unnecessary conversion.
2. Proposed solution
A single library which is used by each framework. This makes sure there is one library the community can focus on, which in turn makes people do less work double. Conversion will not be needed anymore and a good standard will make sure everyone is on the same page.
2. How will you bring this project to a succes
The main idea is to combine all the good parts of the existing implementations of webservers, frameworks and clients into an independent HTTP messaging library.
It is to be used for both web servers and clients, and also for internal use in web frameworks like Seaside, Aida and Iliad, to avoid unnecessary converting as it happens now.
In the end, a reference application in Swazoo will be delivered alongside the library.
The reference application could be based on an existing application. This lets us know how easy or hard it is to rewrite current applications using this library
The library itself will be written using the Grease and Sport portability libarires.
3. Suggested timeline and milestones
A first time block will be spent reviewing current implementation and contacting people who have been working on these implementations.
A selection will be made which ideas and implementations to keep and use and which to let go.
A second time block will be spent on the real implementation and testing in smalltalk of the basic features of the HTTP protocol. These include all the methods (POST, GET, HEAD, OPTION, PUT, DELETE, TRACE, CONNECT) and persistent connections.
In the third time block extended features like access authentication, content negotiation and caching will be implemented.
The reference application will be devel
oped along the way. As more features are implementated in the library, the application will expand it's functionality.
Unit tests will test each feature as developement goes.
For detailed timing:
Research and decision taking: 14 days: May 24th till June 10th
Contacting different parties and discussing: 21 days: May 24th till June 21st
Implementing basic HTTP features: (after research and decision) 30 days: June 11th till July 22th
Creating a reference application and writing unit tests for implemented HTTP features: Starting June 11th, till the end of the project.
Implementing Extended functionality of the HTTP protocol: 30 days: July first till August 11th maximum.
each time frame is chosen such that there's extra time should something go wrong or come up.
I will direct you to the html page with the timing chart:
I've made a detailed schedule in Planner: http://infogroep.be/~icorne/gsoc_http.html
Planner is an open source tool for creating time schedules, this chart is a Gantt chart
4. Possible risks
A first possible risk is that the interested communities don't get along and want totally different things. At that point it is upto me to make a decision based on rational arguments, an in-depth study of the field and the goal of the project (making this library the standard)
Another risk involves focusing on getting the reference application working first and then the library. This will not happen, the library is the key deliverable. If my progress on the library is faster then on the application, I should not wait for the application to finish, but continue development on the library. Afterwards there will be enough time for the application to catch up.
It is also not to be underestimated the complexity and scope of this project. For example, caching could be implemented on top of the library and might not be in the scope of this project. I have experience with the http protocol and implemented it partially for a bachelor thesis. This makes sure I don't underestimate the complexity of key attributes of some methods such as idem potency.
5. What the result will look like
In the end, the smalltalk community will be able to use one library to use HTTP messaging in all of its framew
orks, webservers and clients. An example application will be delivered alongside to show the strengths of this new library and serve as a reference application to interested developpers.
|